Video controller integrated circuits are known in the art for controlling video displays such as CRTs and flat panel displays. Such video controller ICs are typically incorporated into video controllers (e.g., MDA, CGA, EGA, VGA or the like) for use in computer systems (e.g., IBM.TM. PC or the like). Such video controllers also incorporate a video memory (VMEM) for storing video information for forming a video display.
FIG. 3 shows an example of a prior art video controller IC which is presented here for purposes of illustration only. The present invention may also be applied to other types of video controller ICs without departing from the spirit or scope of the invention.
Referring to FIG. 3 there is shown an internal block diagram of a video controller IC 101. System data written to the integrated circuit via system data bus 105, system control bus 106, and system address bus 108 (hereinafter generally referred to as system busses 105, 106, 108) go through CPU interface 120 to control the other elements of video controller IC 101 via an internal data and control bus 125. Status and other data can also be read from the other elements in video controller IC 101 via internal data and control bus 125, CPU interface 120 and system busses 105, 106, 108.
Data written to video controller IC 101, which are intended to be stored in an external video memory (not shown), are written through and modified as necessary by graphics controller 117, then written to memory controller 116. Memory controller 116 drives appropriate values on video memory control bus 109 and video memory address bus 110, and drives data out on video memory data bus 111.
Memory controller 116 is also responsible for reading memory data which is needed to define video data. Memory controller 116 drives appropriate values on video memory control bus 109 and video memory address bus 110, and receives video memory data on video memory data bus 111. Video data is stored in an external video memory (not shown) coupled to video memory busses 109, 110 and 111.
In operation, video data from memory controller 116 passes through video FIFO 118, then is modified as necessary in attribute controller 121 before being output on video output data bus 104. Data on video output data bus is further modified by video output block 123, and driven out on video output 103. Video output block 123 may comprise, for example, a RAMDAC (Random Access Memory Digital to Analog Converter). Video signals entering the RAMDAC may comprise, for example, data which describe a color to be displayed. This data may define a number representative of a particular color, but not necessarily the color itself. The RAM portion of the RAMDAC contains a lookup table which converts this number into a digital signal representing a color value. The contents of the lookup table can be altered by software such that a particular color value can be assigned to a different number (or vice versa). The DAC portion of the RAMDAC converts this color value to an analog output, for example, analog VGA or the like, which is then transmitted on video output 103.
CRT controller 119 generates the signals of video output control bus 102. Memory controller 116 uses one of internal clocks 126. CRT controller 119, video FIFO 118, attribute controller 121, and video output 123 use a different, asynchronous one of internal clocks 126. Techniques known in the art are used to synchronize the transfer of data from memory controller 116 to video FIFO 118. In normal operation, internal clocks 126 are generated by clock synthesizer 122, which may use system reference clock 107.
Signature generator 124 can be used for testing in either the test environment or in normal operation. Signature generator 124 takes as its inputs video output control bus 102, video output data bus 104, control information over internal data and control bus 125 from CPU interface 120, and the same asynchronous one of internal clocks 126 which was used by CRT controller 119, video FIFO 118, attribute controller 121, and video output 123.
Video controllers typically use one of two modes to display information on a video display. A graphics mode may be used to display graphics information (e.g., drawings, pictures, or the like) from information typically stored as a bit map in the video memory. Such graphics information is typically stored in the video memory, arranged into four bit planes. An alphanumeric (or text) mode is also provided to display text only (or primitive graphics produced from text-like characters). Although alphanumeric modes are not as versatile as graphics modes, they are generally faster in terms of screen refresh rates.
In a video controller IC, graphics modes may require large amounts of memory to display information, along with long refresh times. In order to quickly process alphanumeric characters, alphanumeric modes are provided to compress the amount of data needed for each screen by providing a character set font bit map describing the pixel arrangement of each character in a character set. FIG. 2 shows how the video memory of a typical VGA controller is arranged in a alphanumeric mode.
Alphanumeric characters may be displayed in a variety of colors or various monochrome attributes. In monochrome modes, characters may be represented in low or high intensity, in reverse intensity, with underlines, or blinking. In color alphanumeric modes, one of a number (e.g., 16) of colors may be selected for the foreground, and another for the background of each character. In addition, the characters in the color mode may be commanded to blink or be underlined. In either color or monochrome mode, the one byte used for each character is called the character attribute and is stored in plane 1 of the video memory as shown in FIG. 2.
The character code may consist of a byte of data, typically an ASCII code describing the character. For example ASCII code 64 (Decimal) would represent the character "A". The character code may take one of 256 values (e.g., 00 (Hex) to FF (Hex)) in a character set, requiring eight bits (one byte) for each character. These character codes may be stored in plane 0 of the video memory as shown in FIG. 2.
The shape for each of the 512 characters, which may be generated from the character codes, may be stored as a bit map in plane 2 as shown in FIG. 2. Two or more character set font bit maps may be stored in memory. Typically, two "local" default character set font bit maps may be stored in BIOS ROM in a video controller IC. Additional "user" character set font bit maps may be loaded from RAM by a user. Two character sets may be active at one time, providing a total of 512 characters which may be displayed. Each font bit map describes the shape of each character in a pixel map, where one bit represents one pixel.
Different character sets may have different numbers of pixels per character. For example, in an EGA display, three character sets of resolutions may be provided, 8.times.8 pixels, 8.times.14 pixels (as shown in FIG. 1) and 9.times.14 pixels. Typical VGA displays support 8.times.8, 8.times.14, 8.times.16, 9.times.14 and 9.times.16 pixels characters.
Each character is represented in memory by a group of bytes, each byte typically representing a horizontal scan line. The total number of bytes may represent the overall height of the character. For example, the character shown in FIG. 1 may be stored as a bit map comprising fourteen bytes, each byte representing one scan line of the character "Z". The contents of byte 2, for example, would be FF (hex) or 11111111. The contents of byte 6 would be 18 hex, or 00011000. In most VGA/EGA controllers, 32 bytes may be reserved for each character regardless of the number of actual bytes used for the bit map of the character. Thus, a character set of 256 characters will require 8192 bytes, or 8 KB, of memory space.
Other types of bit mapping are possible. For example, some video controllers reverse the LSB and MSB. Further, for pixel resolutions greater than eight bits per scan line per character, more than one byte may be used per scan line of a character.
In the alphanumeric mode, most VGA or EGA video controller ICs do not utilize the fourth plane of the video memory, as shown in FIG. 2. This fourth plane may be used for specialized expansion modes, or, as discussed below, for mirroring the contents of plane 2 to place the character font bit maps in page mode.
As can be seen from the memory map of FIG. 2, a string of characters and character attributes may be quickly read from planes 0 and 1 (even and odd addresses). In order to access the corresponding bit maps for each character, however, a more complex memory access must be made.
For example, each character bit map may be located in plane 2 by a character shape address which may consist of a character base address plus the font character code. The byte at that address, followed by the next 13 bytes (using the 8.times.14 resolution example shown in FIG. 1), represent the character font bit map for one character.
However, in order for the video controller to assemble a scan line of characters, these character maps cannot be addressed sequentially. Thus, in order to draw three characters, the video controller must first retrieve the first byte of character one, the first byte of character two and then the first byte of character three in order to draw the first scan line. For the second scan line, the video controller must retrieve the second byte of character one, the second byte of character two, and the second byte of character three. This process would be repeated for all fourteen character lines (as shown in the example in FIG. 1). Thus, the video controller must randomly access the video memory to retrieve the character font bit maps. As computer speeds (clock rates) and video refresh rates have increased, this prior art technique for generating alphanumeric characters may be inadequate for high speed generation of text characters.
In prior art video controllers, individual font bit maps may be located in plane 2 of the video memory, arranged in sequential order, in 32 byte blocks. Thus, in order to access individual scan lines of a font bit map, a series of random memory accesses must be made. To fetch the ASCII and attribute bytes (which are located at sequential addresses), the memory may be accesses in page mode, which may, for example, take 50 ns for one page cycle. In order to retrieve one byte of a character fort bit map, plane 2 of the video memory must be accessed in a random cycle which may take 250 ns. Thus, the fetch time for one byte of the character font bit map may take five times as long as the page mode fetch of the ASCII character and attribute data.
One solution to this problem is to place the entire set of fonts in page mode. That is, it may be possible to write the contents of plane 2 of the video memory in to plane 3 of the video memory (or to some other memory location) and reload the fonts in a page mode into plane 2. In page mode, the fonts are arranged by scan line, rather than by ASCII character order. Thus, a first page of a character font bit map may contain 256 bytes, each byte representing the first scan line of each of the 256 characters. The second page of the character font bit map may contain 256 bytes, each byte representing the second scan line of each of the 256 characters. For a 14 line character such as shown in FIG. 1, fourteen pages of page addressable memory may be used to page fonts.
Using the paged font technique, one page access may be made to plane 2 of the video memory to retrieve all the relevant scan lines of all 256 characters, which can be assembled to produce a scan line for the video display using the ASCII and attribute information from planes 0 and 1 of the video memory.
Unfortunately, this technique suffers from at least two drawbacks. First, the technique is not VGA compatible. Since a user may load fonts into the video memory, it is possible that a conflict will arise if the user attempts to load an unpaged font into the video memory set up for paged fonts. Second, the paged font technique discussed above allows for only one font to be displayed at any given time on the screen, since in the page mode of access, all relevant scan lines of each of the 256 characters are retrieved at once.
The present invention overcomes these difficulties by providing a page mode access to allow more than one video font to be used at one time without unduly slowing down the video controller.